Chapter 21
Runtime Replication
"Within the Cube Framework, networking does not replicate construction. It replicates the information required to reconstruct runtime consistently."
Why This Chapter Exists
A runtime object rarely exists on only one machine.
In multiplayer environments, every participating client must observe the same runtime representation.
The Cube Framework deliberately avoids treating networking as a separate implementation added after gameplay.
Instead, replication is considered part of the runtime architecture itself.
Its responsibility is not to recreate gameplay.
Its responsibility is to distribute the information required to produce the same runtime result everywhere.
Replicating Information Instead of Objects
Traditional multiplayer implementations often focus on replicating objects directly.
The Cube Framework approaches replication differently.
Runtime objects are already the result of Runtime Assembly.
Rather than transmitting every implementation detail, the framework replicates the runtime information required for another machine to assemble the same result.
Every client therefore participates in the same architectural process.
Construction remains deterministic.
Replication becomes significantly more predictable.
Runtime State as the Source of Truth
The replicated information represents the current Runtime State.
Build identifiers.
Runtime data.
Component information.
Statistics.
These values describe the current state of the assembled runtime object.
Whenever this state changes, replication distributes the updated information.
Every receiving client reconstructs the same architectural representation.
Reconstruction Instead of Duplication
One of the defining characteristics of the Cube Framework is that replicated clients do not receive handcrafted runtime objects.
Instead, they receive enough information to reconstruct the runtime object locally.
The same Runtime Assembly process that produced the original runtime object also produces the replicated version.
Networking therefore reuses the architecture instead of replacing it.
Supporting Late Join
Late joining clients present a unique challenge.
They were not present while the runtime object was originally assembled.
The Cube Framework solves this by replicating the current Runtime State rather than replaying historical events.
When a new client joins, it receives the information required to reconstruct the current runtime representation directly.
No historical reconstruction is necessary.
The runtime object simply becomes available in its current state.
Network Relevancy
Runtime objects are not always relevant to every client.
Objects may become network relevant.
Later become irrelevant.
Then become relevant again.
Rather than treating these situations as special cases, the Cube Framework handles them through the same reconstruction process.
Whenever replication resumes, the receiving client reconstructs the current Runtime State using the replicated information.
The architectural process remains identical.
Only the timing changes.
Networking as Infrastructure
Gameplay systems should rarely concern themselves with replication.
Instead, networking belongs to the infrastructure layer of the Cube Framework.
Gameplay modifies Runtime State.
The networking layer distributes Runtime State.
Runtime Assembly reconstructs Runtime State.
Each subsystem performs one responsibility.
Together they produce consistent multiplayer behavior.
A Shared Networking Philosophy
Although the current implementation focuses on modular weapons, the architectural philosophy extends across the entire Cube ecosystem.
Vehicles.
Equipment.
Characters.
Interactive world objects.
Every future runtime module can rely on the same replication strategy.
Replicate the Runtime State.
Reconstruct the runtime object.
Continue gameplay.
The architecture remains consistent regardless of the gameplay domain.
Design Note
Whenever new runtime information must be synchronized, avoid replicating implementation details directly.
Instead ask:
"Does another machine have enough information to reconstruct the same Runtime State?"
Replication should communicate architectural state rather than implementation.
Framework Law XXI
Within the Cube Framework, replication distributes Runtime State—not handcrafted runtime objects.
Every machine participates in the same Runtime Assembly process.
Networking simply ensures they begin from the same information.
Looking Ahead
Replication allows multiple machines to maintain the same Runtime State.
The final chapter of Part III explores how the architectural systems introduced throughout this part cooperate while remaining independent from one another.
Revision History
Version 1.0
Initial publication.